第4章 コメント（Clean Code）
適切なコメントの使用方法とは、コードでうまく表現することに失敗したときに、それを補うのに使うことです。 (Kindle の位置No.1758-1760)
コメントは失敗
意図がコメントなしでは表現できない時
コード自体で説明できない時（「不明確なつながり」より）
せいぜいよくて必要悪
必要悪とは、ない方が望ましいが，組織などの運営上また社会生活上，やむをえず必要とされる物事。（スーパー大辞林より）
コメントを使わずにコードで表現する
コメントを最小限とするための多大な努力をすべき
（IMO：『リーダブルコード』とはぜんぜん違う意見）
コメントで、ダメなコードを取り繕うことはできない
コメント入りの雑然とした複雑なコードよりも、コメントがほとんどない、きれいで表現豊かなコードのほうがずっと優れています。(Kindle の位置No.1792-1793)
自分自身をコードの中で説明する
意図をコードに込める
関数を作るだけでも意図を込められる（関数名）
よいコメント
限られたケース
書かずに済ますよりも優れたコメントはない (Kindle の位置No.1806-1807)
コメントで情報を与えるよりは、関数名やクラス名（コメントを不要にする）
決定の裏に隠された意図を伝える
結果に対する警告
TODOコメント
好ましくないコードの放置よりは、現在はできないとしたTODOコメントのほうがよいという立場
公開APIにはJavadoc
よくないコメント
コメントを書くのであれば、十分な時間をかけて、最善のコメントを残さなければなりません。(Kindle の位置No.1911-1912)
（シャンクスの「銃を抜いたからには 命を懸けろよ」思い出す）
コメント書くよりコードをきれいにしよう
コメントの箇所を見るだけで意味がわかるべき
コード自体を上回る情報を提供しないコメントのはよくない
（IMO：進次郎コメント）
Tomcatにある「冗長で無駄な大量のJavadoc」
新しい情報がないと読み飛ばす（ノイズコメントより）
本来読まれるべきコメントが読まれなくなってしまう
バナーについて、なるべく使わず、効果が最大になるときに限って使う（＝乱発しない）
ソースコード管理システムに任せるべき
日誌
署名
関数や変数が使用できるのであれば、コメントを使用しないこと
小さく要約された関数
コードのコメントアウトほど、いやな慣習はあまりありません。絶対にやめましょう！(Kindle の位置No.2075)
ソースコード管理システムに任せて消す
興味深い議論の履歴とか、過度に詳細な記述などをコメントに入れてはいけません。(Kindle の位置No.2114-2115)
外部に公開されて使われるコードでないならば、Javadocは忌まわしいものになってしまいます。(Kindle の位置No.2138)
TODO：例を写経したい
エラトステネスの篩
コメントの使用は控えられ、2箇所だけになる
アルゴリズムの理解に導く（ただし詳細すぎない）
コードの意図の説明
参考文献